Today also FIAMM01 (Carabinieri) had some flyover near CEB (08:40 UTC)
The estimated distance is ~ 200m, the height was ~ 200m (credits: flightradar24), well inside the NOTAM area.
The signal is very clearly visible in the CEB microphones. The ITF was unlocked (maintenance).
DRAFT - REPORT IN PROGRESS - will be finalized at the end of the shift
Upon arrival, I found the ITF locked and in SCIENCE mode.
At 6:05 UTC I set the MAINTENANCE mode. Here is the list of the activities communicated to the Control Room:
- Cleaning of the Central Building and the DET Lab (external firm managed by Menzione);
- TCS chiller refill (Menzione);
- Replacement of the electric post-heating coil for the AHU 1_SX of the Mode Cleaner from 6:20 UTC (ongoing, external firm managed by Soldani);
- Checks on the HVAC plants (Soldani);
- ELE_QGBT process update (Ballardin);
- ENV_MCB_MAG_N magnetometer substitution, see #64189 (Paoletti)
During the shift, I performed these periodic tasks:
- At 6:10 UTC I set the SINGLE_BOUNCE_NI state. OMC locked from 6:30 UTC to 6:35 UTC. OMC scan performed from 6:45 UTC to 7:06 UTC;
- Check of IMC working point and position from 7:20 UTC to 7:30 UTC;
- Acquisition of TCS thermal camera references at 7:47 UTC;
- At 9:00 UTC checks on TCS powers (see table below for results);
| CH | IN | OUT | |
| WI pickoff | 0.271 | 0 | 0.212 |
| NI Pickoff | 0.662 | 0.053 | 0.590 |
At 9:03 UTC the horizontal position control loop opened. I closed it at 9:28 UTC.
The weather station did not transmit during a long time (to be quantified). I disconnected it and checked the serial-to-Ethernet on bench with an universal power supply, since it is very difficult extracting its own jack from the box on the wall. No response, and FPGA very hot. No spares of the same kind presently available, only one Netcom Plus 211 with a different supply connection.
I leave the Meteo station disconnected and the box opened, as long as we find a solution.
The process ELE_QGBT interrogates different electrical nodes; when a node does not respond the process automatically goes into the Error state. Obviously, data related to that node is not sent to the DAQ. When the problem disappears, the process automatically goes in the Golden state (so it not necessary to restart the process from VPM) and the slow monitor date is sent again to DAQ.
Today at 10h24 LT I put in operation a new version (v6r9) of this server to try to detect nodes generating problems. In this new version when a node does not respond, the ELE_QGBT goes in Active State and not in Error State.
Figure 1, the 157Hz bump decrease in the first hour of each lock, Figure 2 during the shift yesterday it did not decrease because the MICH SET loop was intentionally disable for an hour, and then MICH SET adjusted quickly by hand.
Figure 3 confirms that RIN coupling due to a MICH offset is the dominant coupling path fo the 157Hz bump. Blue was with a large RIN coupling to DARM, red and yellow are with the coupling intentionally increased by adding a MICH offset in the wrong direction, and green purple and green are with the MICH offset adjusted to minimize the RIN coupling (at 1.5kHz).
Figure 4. As seen benfore when the PRCL offset is adjusted to minimize the frequency to amplitude conversion on B2 (blue and red lines), the B2 Audio spectrum is much cleaner, especially at high frequency.
Figure 5 and 6 what is surprising is that looking at the B2 quadrants. In the vertical direction the coupling of frequency noise (227Hz line) decrease in the vertical direction by a factor few, but in the horizontal direction there is no significant change. Does that mean that the coupling has a significant contribution of HOM? Note that this is true only for B2 QD1, on B2 QD2 the line at 227Hz is not visible in neither the H nor V direction, at any of the times. And on both quadrant the sum channel sees the line clearly and decreases by a factor 10 when adjusting the PRCL offset.
/users/mwas/ISC/RINanalysis_20240506/analyseRIN.m
The probe has been removed today from the MC tube, during the maintenance.
The ENV_MCB_MAG_N magnetometer was defective as of October 2, 2023 at 00:03:05 UTC.
Today we changed it with a new one (MFS-06e). We also had to use a different type of cable (the new magnetometer uses a different connector), via an adapter.
The signals seem to have returned to normal values.
This morning, the threshold on SDB1_slow_shutter_OMC1_T1_fast_RMS used to monitor the closing of the slow shutter has been adjusted to 6e-9. DetMoni restarted at 07h19m23 utc.
ITF in Science mode for all the shift.
Guard tours (time in UTC)
From 21:00 to 21:30; from 23:00 to 23:30; from 1:30 to 2:00; from 3:30 to 4:00
In this afternoon shift science mode stopped from 15:35UTC to 18:30UTC for daily calibration and commissioning (RIN coupling vs MICH and PRCL offsets), the ITF unlocked at 15:58UTC with a DOWN command from my ITF_LOCK client, I missclicked on the metatron client instead to set DOWN the CALI node I did it for ITF_LOCK without realizing it; the relock was a bit longer with three fails two locking at CARM_NULL_1F and one meanwhile locking the OMC (#64183).
-guard tours(UTC):
17:11 --> 17:39
19:03 --> 19:30
Air Conditioning
from 14:50UTC the MC building air conditioning started to malfunction with a little increasing of the hall temperature (see plot); experts aware of the problem, an extraordinary maintenance of the system is foreseen for tomorrow.
Calibration
- 15:36UTC: CALIBRATING_DF_DAILY;
Shift started with a couple of unlocks.
17:56 UTC turned off MICH SET loop (putting MICH_SET_CAL to zero)
MICH set loop had not converged, so PSTAB was not yet at zero.
18:00 UTC (5min) PRCL set = 8.0 to zero the frequency to amplitude conversion on B2.
18:06 UTC (5min) PRCL set = 8.0, MICH set = -5.0, to increase PSTAB to DARM coupling
18:13 UTC (5min) PRCL set = 0.0, MICH set = -5.0
18:23 UTC (5min) PRCL set = 0.0, MICH set = 12.0 to zero the PSTAB to DARM coupling
18:29 putting back MICH SET loop (cali at -100000)
Figure 1. I have noticed any changes in the sensitivity during this test, appart from the 157Hz bump getting smaller when changing the MICH set to zero the PSTAB to DARM coupling. To be checked more carrefully if MICH set is really the cause.
Figure 2. Summarizes the change in PRCL and MICH offset. A PRCL offset of 8 changes the PSTAB to DARM coupling by about the same amount as a change of MICH offset of 5.
https://git.ligo.org/virgo/commissioning/commissioning-tasks/-/issues/52
Figure 1, the 157Hz bump decrease in the first hour of each lock, Figure 2 during the shift yesterday it did not decrease because the MICH SET loop was intentionally disable for an hour, and then MICH SET adjusted quickly by hand.
Figure 3 confirms that RIN coupling due to a MICH offset is the dominant coupling path fo the 157Hz bump. Blue was with a large RIN coupling to DARM, red and yellow are with the coupling intentionally increased by adding a MICH offset in the wrong direction, and green purple and green are with the MICH offset adjusted to minimize the RIN coupling (at 1.5kHz).
Figure 4. As seen benfore when the PRCL offset is adjusted to minimize the frequency to amplitude conversion on B2 (blue and red lines), the B2 Audio spectrum is much cleaner, especially at high frequency.
Figure 5 and 6 what is surprising is that looking at the B2 quadrants. In the vertical direction the coupling of frequency noise (227Hz line) decrease in the vertical direction by a factor few, but in the horizontal direction there is no significant change. Does that mean that the coupling has a significant contribution of HOM? Note that this is true only for B2 QD1, on B2 QD2 the line at 227Hz is not visible in neither the H nor V direction, at any of the times. And on both quadrant the sum channel sees the line clearly and decreases by a factor 10 when adjusting the PRCL offset.
/users/mwas/ISC/RINanalysis_20240506/analyseRIN.m
Today during the lock acquisition I have noticed that there was power on B1 PD1 while trying to lock the OMC.
Figure 1 shows fluctuation on B1 PD1 even though the voltage bias is off.
Pressing the close button of the shutter in vpm worked to close it, but before that I panicked and closed B1 PD3 and turned off its voltage bias instead. Which caused an unlock first as DET_MAIN has seen the B1 PD3 being turned off and put the interferometer in DOWN.
Maybe the B1 PD shutters are starting to be stuck again because the interferometer locks are becoming too long, and they are not open/closed often enough. We may need to add checks in the automation to check they are indeed closed.
The DCP measurement is likely just a witness of something else changing.
Figure 1 shows the same as on Paolo's figure, the optical gain changes from 3e9 to 2.9e9 and the DCP frequency changes by ~5Hz.
Figure 2 shows the squeezing test of last week. The SR TY set point was changed intentionally by ~25Hz, and the optical gain changed from 3e9 to 2.85e9.
So the change in DCP that occured during the weekend could explain only ~30% of the change in optical gain.
From the recent long lock, one can notice that two small drops of the range happen together with drops of the optical gain. At the same time, the double cavity pole measured by Hrec increases a bit, while the one measured by ACL is kept constant by SR_TY loop. A possible guess is that the error signal of SR_TY loop is sometimes slightly corrupted by something which does not affect the DCP computation done by Hrec. The effect would be eventually a little change of SR_TY working point and a consequent increase of the actual DCP, together with an increase of mystery noise. But we should also consider the possibility that the optical gain is changing because of something else and the measurement of DCP is just a witness of that. We should check if a change of DCP by 4 Hz can explain the visible drop of optical gain, or usually a larger DCP variation is required.
I would also add that maybe we could acquire some day of data at a lower DCP setting, in order to check if the current setting is still the one which maximizes the range.
The DCP measurement is likely just a witness of something else changing.
Figure 1 shows the same as on Paolo's figure, the optical gain changes from 3e9 to 2.9e9 and the DCP frequency changes by ~5Hz.
Figure 2 shows the squeezing test of last week. The SR TY set point was changed intentionally by ~25Hz, and the optical gain changed from 3e9 to 2.85e9.
So the change in DCP that occured during the weekend could explain only ~30% of the change in optical gain.
Today at 13:00 LT we could see an airplane flying over the main building, probably just departed from the lane nearby; one minute later it can be spotted in the CEB microphone signals, but it did not have an impact on Hrec; some 25 minutes later it probably came back along the same route, luckily causing no effect again on the sensitivity.
ITF found in LOW_NOISE_3_SQZ and in Science Mode. It kept the lock for the whole shift.
Sub-system reportsDAQ
From around 10:39 UTC the process ELE_QGBT was reported as not responding on VPM (Orange State) and as not working on DMS (red flag). At 10:46 UTC I restarted the process via VPM to restore the nominal condition.
The process ELE_QGBT interrogates different electrical nodes; when a node does not respond the process automatically goes into the Error state. Obviously, data related to that node is not sent to the DAQ. When the problem disappears, the process automatically goes in the Golden state (so it not necessary to restart the process from VPM) and the slow monitor date is sent again to DAQ.
Today at 10h24 LT I put in operation a new version (v6r9) of this server to try to detect nodes generating problems. In this new version when a node does not respond, the ELE_QGBT goes in Active State and not in Error State.
In a similar way to how the PRC gain is computed using the phase camera, I computed the dark port transfer function of the carrier using the B1p phase camera data.
I used 10 mins of the single bounce data during the OMC calibration as Pref and looked at 10mins of data after 1 hour of science mode (Pscience). The dark port transfer function for the carrier is then: TF = Pscience/Pref*Tprm*Tbs*Rinput*Tbs*Tsrm
Using the values from the OptChar page:
Tprm = 0.04835; Tsrm = 0.396; Tbs = 0.5; Rinput = 1-0.01377;
The dark port transfer function is shown after 1 hour of science run is shown in figure 1.
Using the input power (17 W), we can estimate the carrier power in the dark port, shown in figure 2. On average, after 1 hour of science mode the carrier power at the dark port was 0.0884 W, versus 0.1034 at the start of science mode.
ITF in Science mode for all the shift
Software
At 22:27 UTC I stopped and restarted the process ELE_QGBT because it was not running porperly.
Guard tours (time in UTC)
from 21:50 to 23:20; from 00:00 to 00:30; from 2:00 to 2:30; from 3:50 to 4:20
ITF found in LOW_NOISE_3_SQZ and in Science Mode. It kept the lock for the whole shift.
Guard Tours (UTC):
5:01 - 5:28
7:01 - 7:30
9:11 - 9:38
11:01 - 11:30
I found ITF in SCIENCE; It remained locked for the whole shift.
ITF found in Science.
At 15:14 UTC the DMS reported a jump in the power DAS OUT; I immediately contacted the TCS on-call. From remote Ilaria adjusted the TCS WI chiller setpoint and thanks to this operation we could recover the standard value of the power DAS OUT without breaking Science mode (see entry 64172.
At 20:34 UTC ITF in Calibration for the planned calibrations (the planned starting time was delayed by LIGO):
At 21:05 UTC ITF back in Science mode.
No DMS alerts in the shift.
Francesco called me because of the change of state of WI CO2 laser.
To restore the standard condition, I adjusted the WI chiller set point from 19.04 degrees to 19.05 degrees (15.40 UTC).
The BCK chiller set point has been chaged accordingly.
